Add Playwright E2E suite; fix work-entry date persistence and cascade delete - #917

Summary

New e2e/ Playwright project (20 tests, all passing) covering login, client CRUD, the work-entry lifecycle, report totals + CSV export, and input edge cases. Tests run against the real backend/frontend — playwright.config.ts boots backend (3001) and frontend (5173) via webServer and reuses already-running servers.

Two application bugs the suite surfaced, plus one testability change:

Work-entry dates were persisted as epoch millis. Joi.date().iso() coerces date to a Date, which sqlite3 binds as a number, so the API and the CSV/PDF exports returned 1786320000000 instead of 2026-08-10:

Date,Hours,Description,Created At
1786320000000,2.5,,...      # before
2026-08-10,2.5,,...         # after

workEntries.js now normalizes to a calendar day (toDateOnly) on insert and update. Covered by the CSV export assertion in reports.spec.ts.

ON DELETE CASCADE was never enforced — sqlite defaults foreign_keys off, so deleting a client left orphaned work_entries rows (invisible in listings only because the list query INNER JOINs clients). initializeDatabase now runs PRAGMA foreign_keys = ON.

Rate limit is configurable via RATE_LIMIT_MAX / RATE_LIMIT_WINDOW_MS (defaults unchanged at 100 / 15 min). The global 100-requests-per-IP limit throttles a full suite run, so the E2E webServer raises it.

Test isolation comes from the app's own model: each test logs in with a unique email, and all data is scoped by user_email, so no cleanup is needed against the in-memory DB.

Backend unit tests (161) and the frontend lint/build still pass.

Link to Devin session: https://partner-workshops.devinenterprise.com/sessions/7790300b33bf44b7b56f9a98100e185c